IBIS Macromodel Task Group Meeting date: 12 July 2016 Members (asterisk for those attending): ANSYS: * Dan Dvorscak * Curtis Clark Broadcom (Avago): Xingdong Dai * Bob Miller Cadence Design Systems: * Ambrish Varma Brad Brim Kumar Keshavan Ken Willis Cisco: Seungyong (Brian) Baek eASIC: David Banas Marc Kowalski Ericsson: Anders Ekholm GlobalFoundries: Steve Parker IBM Luis Armenta Intel: Michael Mirmak Keysight Technologies: * Fangyi Rao * Radek Biernacki Ming Yan Maxim Integrated Products: Hassan Rafat Mentor Graphics: John Angulo * Arpad Muranyi Micron Technology: * Randy Wolff Justin Butterfield QLogic Corp.: James Zhou Andy Joy SiSoft: * Walter Katz Todd Westerhoff * Mike LaBonte Synopsys: Rita Horner * Kevin Li Teraspeed Consulting Group: Scott McMorrow Teraspeed Labs: * Bob Ross TI: Alfred Chong The meeting was led by Arpad Muranyi. -------------------------------------------------------------------------------- Opens: - None. ------------- Review of ARs: - Ambrish to check for a collaborator's feedback on his nearly ready new version of the Backchannel proposal. - In progress. Ambrish reported that he had recently heard back from one of the collaborators and would be reviewing their input. -------------------------- Call for patent disclosure: - None. ------------------------- Review of Meeting Minutes: - Arpad: Does anyone have any comments or corrections? [none] - Bob R.: Motion to approve the minutes. - Dan: Second. - Arpad: Anyone opposed? [none] ------------- New Discussion: New Redriver Flow Proposal: - Discussion: Fangyi reported that he continues to work on drafting the actual BIRD. Improved C_comp proposal: - Discussion: Randy noted that he has an updated BIRD draft ready to be introduced. (Note: We did not get to this topic, as Bob Ross' "Pin Reference Concerns" presentation (below) took the entire meeting). Pin Reference BIRD: - Bob R.: [sharing "Pin Reference Concerns" presentation] - [slide 2 - Main Points] - Editorial comments on the BIRD text itself. - Threshold subtleties (scaling) too big a topic and a separate topic that should not be discussed in this BIRD. - Alternate interpretations of the purpose of the [Pin Reference] BIRD? - [slide 3 - Editorial Comments] - Put this section after the last keyword where a bus_label can be declared. - Avoid forward referencing, and utilize the fact that bus_label and signal_name will be well defined already. - Remove pin_name as a sub-parameter. - The first column used in the keyword (pin_name in this case) is not typically listed as a sub-parameter. - Remove "with model thresholds" at the end of the first sentence in Usage Rules. Don't open Pandora's box and discuss thresholding here. - Strike various language defining bus_label or signal_name. They are properly described earlier in the spec. - Also, suggest adding a sentence stating that each line in the [Pin Reference] has a first column containing the pin_name and a second column containing the bus_label (signal_name), as is done in the Usage Rules section of other keywords. - [Slide 4 - Editorial Comments continued...] - In the Other Notes section, add "described later in the Buffer Modeling Section" to handle the forward referencing of the [* Reference] keywords. - Also add a forward referencing statement for the mention of C_comp. - Possibly controversial: Suggest that for ECL models the EDA tool should use the pullup_ref entry under the [Pin Mapping] keyword. - [Slide 5 - Editorial Comments continued...] - Cleanup of the Example: - Remove VSS, it doesn't exist in this example. - Change VEE to -3.2V, a more traditional value. - Could delete the [Model] section but provide voltage details as comments in the [Pin] section. - Could add an Output Pin example as a second entry in [Pin Reference]. - (Note: the indention of the [Pin Mapping] keyword on this slide is a simple typo). - We might consider adding a second example, for example RS232. - [Slide 6 - Legal ECL Test Setup and Operation] - In a real PECL device Vss does not always exist. - Schematic representation of a real set-up for extracting timing test load sample waveforms or for v(t) extraction. - No Ground Pin connection. No device Pin connected to test fixture ground. - Vee at -3.2V relative to test fixture ground. - Vcc at 2.0V relative to test fixture ground. - "Device Under Test" symbol represents die and package. Lines that touch that symbol are the pin and probe locations on the DUT. - [Slide 7 - C_comp] - Possible complications for choosing a default reference terminal for ECL. - [Slide 8 - PECL Gate with a Normal Load] - Not concerned with the Input portion for this discussion. - Everything in the "box" on the figure is in the Silicon. The package is is also included in the box. - Discussion: Walter noted that the picture has 4 pins on the right side (VCC, VEE, Vout+, Vout-). He asked where the ground symbol on the schematic (inside the "box") was connected. Bob stated that it might be connected to Vee. Walter said in that case Vee would be "0V", but otherwise that ground symbol must represent a connection to some other pin on the device, right? Bob asked that we wait until we reviewed the other slides before addressing this question. - [Slide 9 - PECL IBIS Output Simulation] - IBIS Model setup. No different than slide 8. - The Pin Interface is the bold dashed line. - Right hand side of this line is the measurement extraction setup. - Discussion: Walter asked what the on chip reference point for the VCC = 5.0V shown on the left of the dashed line would be. Arpad suggested that the ground symbol shown on the left side was actually connected to the VEE line shown, and that it would be the reference terminal. Radek agreed and noted that the assumptions that were not spelled out were that Vref is driven with VCC - 2.0V, and that VEE is implicitly considered the same as ground in this example. The Vref is driven externally (that info not even known to the IBIS file), and the assumption is that the receiver at the other end would be properly biased as well. Bob suggested that the following slide would get to the heart of Walter's line of questioning. - [Slide 10 - Split PECL IBIS Output Simulation ... No VSS Pin] - This is the case Walter is trying to get at. - VCC = 2.0V, VEE = -3.2V. Those are the only two voltages provided to the device. - One of the conclusions of the [Pin Reference] discussion had been that there must be a test fixture ground reference VSS Pin. [this split PECL is a counter example] - Discussion: Arpad noted that this slide also contained the Vcc and the ground symbol on the left side of the dashed line. He asked if the ground symbol would be considered connected to the VEE or the GND shown on the right (external). Bob said that in the IBIS model is not clear, and the note (bottom left) points out that some tools might connect it to VEE in any event. Walter asked how one could measure VCC = 2.0V on the Silicon, and Bob said that you could not do so in this split PECL configuration. All one could measure on the Silicon was (VCC,VEE) = 5.2V. Bob noted that the external voltage circuitry being driven by a PECL device is critical to the flow, and that there really is no "VSS = 0V" Pin anywhere on this device. Bob said that such a device could be modeled with an IBIS file that had only -3.2V and 2.0V provided as [* Reference] values, and tools could simulate it properly by assuming a global ground "node 0" GND. Radek noted that we have to distinguish between measurement setup and simulation. This figure, Vref = 0, is showing the specific biasing for setting up the Vfix, Rfix, etc., and doing the extraction. When you have this device in action, then you don't have this 0.0V and all you have is the 5.2V difference between the rail terminals. Now the output voltage has to be properly defined with respect to what? Walter said he thought this was pointing back to his DUT_ref_terminal BIRD, which would have allowed VEE to be specified as the reference terminal, other terminal voltages (Pullup_reference and Vout) to be computed relative to VEE, and then the -3.2 would be added back in to those values to convert back to the DUT conditions recorded in the IBIS file. In this case, one would have to reference Vout and VCC to VEE. In other cases, like RS232, one would make measurements relative to an actual ground pin. To get a voltage value to compare to the values in the IBIS file, one would compute (Vout,Vee) + (-3.2V). In the current version of the BIRD, you would specify the bus_label corresponding to the VEE signal_name coming into the package for this example. For RS232C, the signal_name would be VSS instead. Bob agreed and noted the VSS would be a different Pin in the RS232C example. - [slide 11 ECL Output (another example)] - Here VCC is 0V, which is another standard configuration. - In this case the GND symbol might go to VCC. - Discussion: Radek noted that here one could define the bus_label corresponding to VCC as the reference. In the earlier split PECL example one could define the bus_label corresponding to VEE as the reference. One could also want to provide a bus_label other than VCC or VEE, and you would need a separate bus_label to provide that reference, but the combination of the [Pin Reference] and [DUT_ref_terminal] would facilitate this. Bob noted that there was no disagreement regarding [Pin Reference] itself working for PECL and ECL, but for split PECL there exists a legitimate configuration with no VSS Pin. So for split PECL one could choose VCC or VEE as the reference (most likely VCC for other reasons). - [slide 12 Reference Rail] - VSS pin (DUT test fixture ground connection) may not always exist. - Since [* Reference] contains an ideal voltage relative to DUT test fixture ground, a non-zero value is just as good a reference as a zero value. - [slide 13 - Suggestions, Actions] - Modify the example. - Perhaps add a different default rule for ECL. - A terminal corresponding to a [* Reference] with a value of zero may not always be the best choice for reference. - Be careful using this for thresholds. - Discussion: Walter noted that the last point (thresholds) was related to the scaling issue (if the DIA rails are not simply uniformly shifted relative to the DUT rails then one has to be careful with threshold scaling), and that this is a separate issue for which IBIS doesn't yet have a complete solution. Walter asked if Bob was concluding that an EDA tool could simply use any one of the rails as reference, shift the relative voltages measured with respect to that reference as they see fit, and that we don't need this BIRD it all? We would state that in IBIS the GND, ground symbol, node 0, are simply referring to what's done for device under test. At simulation time, however, one should not assume node 0 is meaningful, as all measurements must be relative to rails at the buffer terminal. Bob said he wasn't ready to dismiss the [Pin Reference] BIRD, but that Walter's statement might be correct. Radek reiterated his position that we should move in the direction of letting the model maker specify the reference for the Vout. Bob noted that [Pin Reference] may be necessary for power aware simulations, and that he was not opposed to the BIRD itself, just its assumption that a Vss pin must always be present. - Arpad: Thank you all for joining. ------------- Next meeting: 19 July 2016 12:00pm PT ------------- IBIS Interconnect SPICE Wish List: 1) Simulator directives